Thread: Can you spot debug? [snake]

Originally Posted by gavra

Holy god you wrote a lot.
Let's begin with my favorite programmer mats.
I'll check those warnnings later [dev is an awful compiler - no warnnings at all].

If you are talking about dev-cpp, then it has exactly the warnings that I posted, since it uses gcc behind the scenes, and that's the compiler I used (in fact, I have dev-cpp/bin as the path to the compiler). You just have to configure your project to have warnings enabled.

I know I may change those gotos, a few months ago I wouldn't even think about using gotos..

In my mind, you were thus a better programmer a few months ago. ;-)

I'll change for one srand in main.
Snake can be done even without the board that I used.
Very nice idea but I'll need to use 2 more variables is that still better?

Not sure what the above two lines refers to. 2 more variables is usually not a big problem - particularly not local variables in a function, as those disappear again when you leave the function.

Thank you, I appreciate your wish to help and believe me you do.
While writing the code I thought about using "while" instead of "for" but I have seen many times the kind of the writing above so I wrote this way.
See this: tmp[i=0]=i;

The above is definitely bad coding, as there's no strict definition of whether the address calculation of tmp[i=0] or sampling the value of i happens first. Different compilers, or even the same compiler under different circumstances (e.g the code before this, the optimization settings, etc) will possibly do different things.

I am checking if there is no highscore.
I tried to do that using the EOF but it made some problem so I quit and do it in another way.
ok.
I tried to make something like this:
snd = !snd;
this way: snd = ~snd;

Not the same thing - although as long as you check "if (snd)" or "if (!snd)" then it would have the same effect - it just will be -1 instead of 1 when it's true.

ofcurse it doesn't work so I went to the "trust way".
You right again, I will move the "if" into the function.
"Why is the function "hidden_readonly" in upper-case when all other functions are lower-case?"
No reason, is that a problem?

Being consistent is important - it's not paritcularly important if you use upper case, lower case or a mixture, as long as there is a defined and consistent pattern. Most people tend to use upper case only symbols for macros.

init() - cause of this: "printf ("#\n#");"

Ok, so split your code differently, have a flag or some other solution for that - the 90% of the code equivalent should rule that you don't repeat it.

--
Mats

I tought you want to print the whole board.
We may put numbers into the board where the snake is, his head will be 1...his tail (=SIZE OF SNAKE) - now it won't make any problem (I think).
But does it help us? - the bug still exist..

It do gives me some warnnings (I have seen warnning with this compiler).

I know it's just gotos makes the "write labor" of the code so simple \:
I promise you I'll change this bad habbit :]

Not a big problem but when others see your code they prefer to see you use variables with "logic" (if you will see a function with arguments like this: temp1, temp2, temp3 what would you think about this programmer?)

tmp[i=0]=0;
better?

Yah I got confuse with binary.

I'll try to as much consistent as I can [:

Ok, it seems to be that I have more work on fixing "little" things then on the whole game XD

Thanks dude.

EDIT:
By the way what "e.g" means?!

tmp[i=0]=0;
better?

Just write:

Code:

i = 0;
tmp[0] = 0;

or if you prefer:

Code:

i = tmp[0] = 0;

Originally Posted by gavra

It do gives me some warnnings (I have seen warnning with this compiler).

I know it's just gotos makes the "write labor" of the code so simple \:
I promise you I'll change this bad habbit :]

Not a big problem but when others see your code they prefer to see you use variables with "logic" (if you will see a function with arguments like this: temp1, temp2, temp3 what would you think about this programmer?)

tmp[i=0]=0;
better?

Yah I got confuse with binary.

I'll try to as much consistent as I can [:

Ok, it seems to be that I have more work on fixing "little" things then on the whole game XD

Thanks dude.

EDIT:
By the way what "e.g" means?!

Starting from the back....
E.g. means "for example".

Often, writing good code means to start with a good solid base. Writing solid functions that are easy to understand and that are clear what they do makes the job of fixing bugs easier, because you can better follow what part of the code gets executed under what circumstances.

It may be more code to write to wrap a piece of code with while than to use a goto - although if your label name is longer than one letter, it's probably shorter with a while. You just have to think a bit more BEFORE you write the code.

Using sensible and descriptive variable names is a good idea. temp1, temp2, temp3 is possibly good in some circumstances, but most times it is not.

I think gcc actually produces SOME warnings at default warning levels - but you get more warnings if you enable -Wall as the warning level - you get even more if you add "-Wextra -pedantic -std=c89". This ensure that the code is standards compliant and well designed.

--
Mats

By the way, you forgot to put a clr() in the start of main

The strange thing on your code is that the head moves but the tail doesn't. It only moves when you eat something. It doesn't seem correct. Am I right?

Anyhow

Put another else like:

Code:

    if (exist)
    {
      board[ti][tj] = 0;
      if (board[ti+1][tj] == DOWN && ti < n)
	      	ti++;
         else if (board[ti-1][tj] == UP && ti > 0)
                 ti--;
         else if (board[ti][tj+1] == RIGHT && tj < m)
                 tj++;
         else if (board[ti][tj-1] == LEFT  && tj > 0)
                 tj--;
	 else
		 printf("EERROOR!");
    }

When it gets the bug you get an error printed. Which mean your calculation is flawed for ti, tj since they won't increase/decrease and you ll get an error.

Also, If you "fold" the snake this might cause an error, cause there will be more than one value around ti, tj and maybe you won't know which one is correct.
E.g.
H ****
*****
****T

ti, tj are at T. If you read first up you ll get an UP value (propably) and do ti++. So now the tail is lost and you won't have correct board[ti][tj]=0. You propably wanted to leave ti as it is and change do tj--.
Am I right?

Thanks mats.

Hum if I understand you currectly the answer is nope.
I don't think you understand the logic of the snake moves.
It works like this:
I am putting the snake's body ('o') in the corrent head ([hi][hj]) then I go to the next step (UP/DOWN/LEFT/RIGHT) and put there the head ('@') now I just need to "delete" the tail.
Now you probably asks your self "how do you track the tail?".
So all the way the head moves "footprints" are being left behind (UP/DOWN/LEFT/RIGHT).
Your example in my array will be like this:
H | LEFT | LEFT | LEFT | UP
UP | RIGHT | RIGHT | RIGHT | RIGHT
LEFT | LEFT | LEFT | LEFT | T
so I'll choose to go left with the tail [cause the left limb equal to "LEFT"].

mats, I don't know why but I have that feeling that you know how to solve up the bug but you don't tell, am I right?

I print the values in the array and sometimes I don't know why the array get the new direction so I can't follow the tail.
Help me find out why it happens \:

I am foollll!!!!
I think I fixed the bug.
See with your own eyes:

Code:

void move(char board[n][m], int x)
{
     board[hi][hj] = direction;
     CHEAT:
     switch (x)
     {
            case UP:
                 {
                     if (direction == DOWN)
                     {
                        x = DOWN;
                        goto CHEAT;
                     }
                     if (hi > 0)
                     {
                        if (board[hi-1][hj] == FOOD)
                           exist = FALSE;
                         direction = UP;
                        hi--;
                     }
                 }                    
                      break;
            case DOWN:
                 {
                     if (direction == UP)
                     {
                        x = UP;
                        goto CHEAT;
                     }
                     if (hi < n)
                     {
                        if (board[hi+1][hj] == FOOD)
                           exist = FALSE;
                         direction = DOWN;
                        hi++;
                     }
                 }
                      break;
            case LEFT:
                 {
                     if (direction == RIGHT)
                     {
                        x = RIGHT;
                        goto CHEAT;
                     }
                     if (hj > 0)
                     {
                        if (board[hi][hj-1] == FOOD)
                           exist = FALSE;
                         direction = LEFT;
                        hj--;
                     }
                 } 
                      break;
            case RIGHT:
                 {
                     if (direction == LEFT)
                     {
                        x = LEFT;
                        goto CHEAT;
                     }
                     if (hj < m)
                     {
                        if (board[hi][hj+1] == FOOD)
                           exist = FALSE;
                         direction = RIGHT;
                        hj++;
                     }
                 } 
                      break;
                      case ESC:
                           {
                               clr();
                               score = 0;
                               len = 3;
                               main();
                           }
     }
     board[hi][hj] = '@';
    if (exist)
    {
      board[ti][tj] = 0;
      if (board[ti+1][tj] == DOWN && ti < n)
         ti++;
         else if (board[ti-1][tj] == UP && ti > 0)
                 ti--;
         else if (board[ti][tj+1] == RIGHT && tj < m)
                 tj++;
         else if (board[ti][tj-1] == LEFT  && tj > 0)
                 tj--;
    }
    else
    {
       if (snd)
          sound(); 
       len++;
       score += len*speed; 
       print_score();
       create_food(board);
       exist = TRUE;
    }
}

I changed the cases and economize some lines that wsn't necessary
I'll fix what you all have said later.
Thanks [:

Originally Posted by gavra

mats, I don't know why but I have that feeling that you know how to solve up the bug but you don't tell, am I right?

No, I don't. What I'm trying to tell you is that your code is messy, and that induces bugs in itself. If the code is simple to read/understand, then it's also easy to see what is wrong with it.

This means:

• Use local varables - global variables are harder to follow, because you have to know what effect any function called has on the global variables.
• Do not use goto's unless it CLEARLY simplifies the code. A while/do-while/for loop is much better, because it's clear what is going [obviously, use for-loops "in the right way"].
• Do not use recursion when you really should be using while/do-while/for. I spent quite a while trying to understand your menu system - and whilst I sort of follow how it works, and I still could not explain why every line of code is there and what it achieves. You may be able to explain how your code works right now, but if you leave it for a few weeks, I bet you can't.

The function called "input" is clearly one that could do with changing to a function that returns a value rather than changing a global value. Then you could remove the global value of "x" - which would make a whole lot of code more clear.

--
Mats

I am surprised.
Humm I hate globals too, I'll change it soon and use pointers.
Ok.
Ok, just 2 things that I don't understand
one is that "I need to explain my code for you?!"
the second: "you want me to explain the whole 650 lines?!"
thanks again [:

Originally Posted by gavra

I am surprised.
Humm I hate globals too, I'll change it soon and use pointers.
Ok.
Ok, just 2 things that I don't understand
one is that "I need to explain my code for you?!"
the second: "you want me to explain the whole 650 lines?!"
thanks again [:

You also can get pretty messy with pointers - they should be used with care and understanding of the needs.

No, you don't (unless you really want to) need to explain the code to me - I'm just saying that I'm pretty experienced in reading other peoples code, and 650 lines of code is not a whole lot - I certainly quite often work on much larger FILES that are part of tens or hundreds of thousands of lines. If I can't understand parts of a 650 line project, then it must be pretty hard to follow.

--
Mats

You just remain my friend so much (you both are pretty experienced).
I'm sure you have seen worse codes then mine, and as I said I don't have much time right now so I'll fix my "messy code" later.

Originally Posted by gavra

You just remain my friend so much (you both are pretty experienced).
I'm sure you have seen worse codes then mine, and as I said I don't have much time right now so I'll fix my "messy code" later.

Sure. I'm just trying to get the message across that you can waste a lot of time trying to fix up messy code, and it's often easier to rewrite it from scratch than to try to fix it up - even if it seems like a lot of work at the time.

--
Mats